home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0541.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  7.9 KB  |  238 lines
  1. These are comment son the second part of Dave's note.
  2. They refer to the new HTTP spec and a hypertextversion of RFC850  which I made
  3. in order to be able to cross-reference to it (and make it prettier).
  4.  
  5. >  Caching
  6. >  -------
  7. >  
  8.  
  9. >  It will be desirable to avoid overloading servers with popular documents by
  10. >  supporting a caching scheme at local servers (or even at browsers?). This
  11. >  implies that document headers should provide sufficient information to make
  12. >  this practical.
  13.  
  14. Like "Expires:" for example. See
  15. http://info.cern.chhypertext/WWW/Protocols/HTTP/Object_Headers.html
  16.  
  17. ...>  
  18.  
  19. >      o   the document header should *always* include a "Date:" field giving
  20. >          the date it was last written to
  21.  
  22. Agreed.  Now why in the spec did I say that Date: was the creation date?
  23. In any event, we need last-modified as well as created dates. I chose
  24. to use the existing Date: field of RFC 850 as the creation date.
  25. I guess the modified date is more available, but if you are tracing things
  26. the creation date is a better thing to file under.  For a mail/news article
  27. of course they are the same.
  28.  
  29. >      o   the "Expires:" field is optional
  30.  
  31. agreed.
  32.  
  33. >      o   the date values should be in a prescribed format to simplify
  34. >          machine interpretation (Is this adequately defined by existing  
  35. RFCs?)
  36.  
  37. agreed. yes it is, in RFC850: in 
  38.  
  39. http://info.cern.ch/hypertext/WWW/Protocols/rfc850/rfc850.html#z10
  40.   
  41.  
  42.   (pretty soon we're going to HAVE to have hypertext mail!).
  43.   
  44.  
  45. >  I think that we need to provide an operation in which the server returns a
  46. >  document only if it is later that a date/time supplied with  the request. If
  47. >  it is the same (or earlier) the server should return a suitable status code
  48. >  and an optional "Cost:" header, see below.
  49.  
  50. Need to look at NNTP here.  We end up getting very close indeed to it.
  51. I would want the functionalty of this search to map onto the NEWNEWS
  52. very nicely.  A newsgroup is just a hypertext list anyway.
  53.  
  54. >  Note that servers shouln't cache documents with restricted readership since
  55. >  each server don't know the restrictions to apply. This requires a further
  56. >  header to identify such documents as being unsuitable for general caching:
  57. >  
  58.  
  59. >      Distribution: restricted | unrestricted
  60.  
  61. Good point.  Not the the distribution of other messages is in the form of
  62. To: and Cc: and Newsgroup: and in fact Distribution:.  (See  
  63. http://info.cern.ch/hypertext/WWW/Protocols/rfc850/rfc850.html#z12)
  64. So you'll need a new fieldname.  If we could only merge the functionality of  
  65. these systems in some cool way, it would be grand.
  66.  
  67. When looking at protection for more than just GET, I came up with the
  68.     Public: *<method>
  69.     Allow: *<method>
  70. lines documented in the list of object headers I mentioned above.
  71.  
  72. >  This header is only needed for documents with restricted readership.
  73. >  An dirty alternative would be to set the expiry date to the same value as
  74. >  supplied with the "Date:" header.
  75.  
  76. Yes but that would not be legally binding.  It could also mean "this document  
  77. is a live status: fetch it as often as you can".
  78.  
  79. >  Copyright & Payments
  80. >  --------------------
  81. >  
  82.  
  83. >  Although the Internet backbone restricts profit making services, many  
  84. subnets,
  85. >  such as University campuses, and company subnets such as HP's have no such
  86. >  problem. Indeed users strongly want access to copyrighted information for
  87. >  which a payment is due.
  88. >  
  89.  
  90. >  My suggestion is that servers are responsible for tracking who accesses what
  91. >  information, and hence how much they owe. For use within Hewlett Packard for
  92. >  library services, we anticipate including some extra headers in the request:
  93. >  
  94.  
  95. >      EmployeeNumber: 148689
  96. >      LocationCode:   8126        (an account number for cross charging)
  97. >  
  98.  
  99. >  This would be stripped off when sending requests to servers outside the HP
  100. >  subnet. These headers are ignored by servers which conform to strict HTPP2.
  101. >  
  102.  
  103. >  I would like the document header to include an optional cost header, e.g.
  104. >  
  105.  
  106. >      Cost: 4.05 US DOLLARS
  107. >      Copyright: Reuters Inc.
  108.  
  109. I note here that both the copyright holder and the account for charging are  
  110. items in some address space, and we ought to be as flexible with these address  
  111. spaces as wit the udi.  So I would propose something like
  112.  
  113.     ChargeTo:  HPInternal:/8126/148689  upto $2.00
  114.     
  115. would be better.  But how does this fit in with authentication?  Once you are
  116. authenticated, your prefered method of paying will be known.  You can't have
  117. charging without authentication!
  118.  
  119. There is a little problem with sending an "upto $2.00" field as it requires  
  120. honesty of the server not to just charge you $2.00 flat!  This is a real  
  121. problem, as otherwise one needs twice the round trip delays, which we really  
  122. object to, if one prefers the fairer
  123.  
  124.     C    GET  junk
  125.     S    No way: you pay $2.00 first
  126.     C    GET junk I promise to pay $2.00
  127.     S    *junk
  128.  
  129.  
  130. >  This would let the users know how much a given document has cost them, as  
  131. well
  132. >  as who owns the copyright. The latter heading is needed since you can't  
  133. always
  134. >  put it in the document, e.g. think of photographic images.
  135. >  
  136.  
  137. >  
  138.  
  139. >  The "Cost: 4.03 US DOLLARS" field
  140. >  
  141.  
  142. >  
  143.  
  144. >  Copyright and Caching
  145. >  ---------------------
  146. >
  147.  
  148. Have you read "Litterary Machines?" That goes into this in a lot of detail,
  149. or at least Xanadu should have done.
  150.  
  151. >  What happens if a copyright protected document is saved in the cache of a
  152. >  local server? We have got to ensure that the rightful owners get paid for
  153. >  access even when the document is obtained from a local server's cache.
  154. >  
  155.  
  156. >  My idea is that for each access, this server should inform the server on  
  157. which
  158. >  the original document resides. 
  159.  
  160.  
  161. yes -- hence we need three classes, free, forpay, restricted.  I wonder whwther  
  162. these were Brewster's 3 types of flag in his proposed WAIS udi.
  163.  
  164. >  The protocol ought to allow for multiple GOT statements (and associated
  165. >  headers in the same message. For this it seems simple enough to require a
  166. >  terminating blank line.
  167.  
  168. Hey, that;s not something you do for one method, it's a change to the whole  
  169. protocol to introduce pipelining.
  170.  
  171. A simple thing in the first instance is to say that it illegal to cache
  172. a for-pay document unless you have a privat earrangement with the owner
  173. about refunding him.  This could be done using a completely separate billing  
  174. process.
  175.  
  176.  
  177. >  Naming Parts of a Multipart body
  178. >  --------------------------------
  179. >  
  180.  
  181. >  It would be nice to use the MIME format's capability to send multiple
  182. >  documents as part of the same message, e.g. an HTML doc with several
  183. >  pictures. To make this work each separate part needs to include the
  184. >  Document Udi in its header, so that the browser can check if it has the
  185. >  document in its local cache (history stack) or whether it needs to make
  186. >  network request for the picture etc.
  187. >  
  188.  
  189. >      DocumentName: Udi
  190.  
  191. Sure.  This is a very useful thing to put in a mail message anyway.
  192. Like
  193.  
  194. Archived-as:
  195. or
  196. Available:
  197.  
  198. >  Effective support for discussion groups
  199. >  ---------------------------------------
  200. >  
  201.  
  202. >  My model is that discussion groups each have unique Udi's. Each discussion
  203. >  group has a sequence of base notes, and each base note is associated with a
  204. >  sequence of responses. I am unsure of how to deal with cross postings!
  205.  
  206. I agree that the POST method is well defined as a method of the
  207. newsgroup class which takes an article as a parameter. In fact, as you say,
  208. cross-posting makes a mess of this, as it involved many groups in one atomic  
  209. operation.  This is a peculiarity of news which makes it difficult to map onto  
  210. the object model.  Any ideas?
  211.  
  212. ...
  213. >  You also need a way of retrieving a given response. One way is to ask for  
  214. the
  215. >  list of Udi's for all the responses,
  216.  
  217. Yes.
  218.  
  219. > another is a command to get a particular
  220. >  response given the Udi for the base note and a sequence number, e.g.
  221.  
  222. No -- not sufficiently stateless.
  223.  
  224. >  I assume the POST command can be accompanied by an html doc as a body.
  225.  
  226. yes
  227.  
  228. >  Looking forward to your comments,
  229. >  
  230.  
  231. >  David Raggett
  232.  
  233. as you see mine got shorter with time...
  234.  
  235. tim
  236.  
  237.  
  238.